Software as a service (“SaaS”) applications are experiencing rapid adoption in today's corporate environments. Such software solutions enable collaboration by employees with people both inside and outside of their organizations. Moreover, SaaS applications can allow accelerated deployment of the right software solutions at the right time as needed for tasks that arise in an organization.
From the employee side, SaaS applications can be the epitome of a “no brainer.” Employees, especially those who have matured in the era of the evolution of cloud computing over the last 10 or so years, generally cannot fathom a world where they do not have access to the best software tools that are available to them to do their jobs at the precise time needed. Moreover, in smaller companies, these SaaS application-competent employees are often a primary-if not the primary-driver of software acquisition decisions because, quite simply, smaller organizations will typically be less likely to have a formal IT department that vets and selects software for implementation in the company. There also often may not be a corporate infrastructure to manage use of the software on an ongoing basis, which may mean that the software acquisition process will continue to be SaaS applications-focused as the company begins to grow. Critically, if these companies scale to a size where a formal IT structure becomes appropriate, the “legacy” SaaS applications may be so embedded within the functions of the company that the existing SaaS applications ecosystem may be carried forward given the likely difficulty of disaggregating a myriad of individually deployed software products that have become central to the operations of the company. Thus, it follows that, once adopted, SaaS applications can be expected to remain in place in a growing organization, and any issues existing with their use will need to be addressed at some time during the company's lifecycle.
Even for mature companies that have implemented formal, embedded IT infrastructures, SaaS application use likely cannot be avoided in the future. As noted, today's employees expect SaaS applications to be available. In organizations that seek to restrict access to SaaS applications, it can be expected that employees will generate work-arounds to give themselves access to the programs they seek, with this perception likely being driven by an expectation that “it is easier to ask for forgiveness than to ask for permission.” Such unauthorized SaaS application-related software, by definition, will not be visible to IT administrators because the users, in fact, intend for them to be hidden from management. Accordingly, IT administrators would not be able to see the actions of users, or “processing events,” with regard to data that must be managed by an organization. For example, sensitive, regulated, and compliance-related data must be managed to maintain its value and, in many cases, to avoid legal liability. Data that travels through and among these unauthorized—and invisible to management—SaaS applications, will be difficult, if not impossible, to properly manage under current computing frameworks. A modem corporate IT policy would prefer not allow employees to utilize SaaS applications programs in their work. There thus currently exists an inherent tension between the likely behavior of employees and IT administrators in the context of SaaS application usage.
To further complicate the modern IT department management structure, persons that need access to sensitive or compliance-related data may not be employed by the organization. For example, consultants, contractors, and freelancers are increasingly engaged to complete company-critical projects, even at larger organizations. These non-employee users will often access sensitive or compliance-related information via SaaS applications on an as-needed basis, even though corporate IT does not always have visibility to their operating systems and/or devices. Such external users will then not be directly subject to the organization's policies, which makes it even more tenuous for the organization's IT department to manage data flow proximate to them. It follows that the organization's obligations to protect sensitive, regulated, and compliance-related data may not be appropriately manageable for these non-employee users in today's computing environments.
This lack of visibility can also extend to the employees themselves: organizations are increasingly allowing employees to “bring their own devices.” This eliminates the often-cumbersome need for employees to carry multiple devices in which one device is appropriated for business use, and the other appropriated for personal use. As opposed to assigning devices to employees to allow IT departments to manage the flow of data through and among that known—and therefore managed—device, IT departments may generally not be given broad access to such personal devices. Such merging of personal information with business information on this single device can therefore result in a lesser ability of an organization to gain access to the device so as to manage corporate data that travels on or through that device. This is at least because of employee privacy issues that may preclude the employer from gaining access to personal data, even if for the purpose of managing the valuable data of the organization. As a result, organizations are finding it problematic to manage data in the evolving situation where employees demand that their employers amend their corporate policies to allow the use of personal devices for the convenience and comfort of the employee, instead of vice versa.
The evolving SaaS applications IT ecosystem gives rise a new problem of data management in an accessible computing environment where access to functionalities and data are provided on demand. That is, in the legacy IT world, access to programs, data, etc. was granted from the IT administrator side of the organization. Employees, devices, and the like were authorized on a server, database, etc. and policies/permissions were applied to grant various levels of access or functionalities thereto. However, in the SaaS computing environment, this command and control system is not possible because there is typically little if any interaction of IT administrators with the underlying SaaS applications program in that the functionalities generated by the respective SaaS programs reside at the application level. This can mean that, not only does an IT department possibly not hold knowledge that a particular SaaS program is being utilized in corporate operations, IT administrators may not be able to manage the movement of sensitive, regulated, or compliance-related data through and among the various programs. In short, one cannot manage what cannot be seen, and data that is transferred at the application level may not be visible to administrators for reasons discussed herein.
Notably, proprietary data holds its value only as long as it remains confidential. As such, data breaches involving proprietary data can result in significant destruction of corporate value. Government regulations also set forth strict requirements for disclosure of regulated data. Indeed, disclosure of some types of data, for example, protected health data, is actionable even if the disclosure was inadvertent and even if no one actually accessed the data. It follows that the reduced ability to manage the transfer of managed data in a SaaS application-driven ecosystem does not reduce the obligations of IT departments to ensure the protection of such data.
To this end, it is not uncommon today for there to be news reports of data breaches in which managed data (e.g., social security numbers, protected health information, personnel records, trade secret information, etc.) have been inappropriately disclosed, even innocently. For example, an employee may access an online document signing SasS program. When a document is uploaded to the cloud to generate the e-signature, any information in that document will also be uploaded. If that information is private, sensitive, regulated etc., the act of uploading the document may constitute a legally actionable data breach.
In yet a further complication that transcends the issues of the evolving cloud computer IT ecosystem and user devices, there exists the overriding problem of SaaS application interoperability. In fact, issues of data and object management in a SaaS computing environment can be traced, at least in part, to issues with the interoperability between and among different SaaS applications that are intended to be functional with and among each other in a cloud computing environment. As would be recognized, SaaS application functionality is imparted by one or more APIs associated with a service or a product. It follows that the coding used to generate each API will underpin the ability of APIs to work together to accomplish a user goal. It can be expected that a single SaaS application vendor will standardize APIs within its own product offerings, at least to ensure that all of the APIs delivered by that single vendor will exhibit interoperability within the vendor's overall product platform. However, standardization among SaaS application vendors is not currently the norm. In other words, the SaaS applications that work together in a single cloud computing environment are likely to be “heterogeneous,” in some respects which, in turn, can lead to some lack of interoperability.
Vendors of platform-level products (e.g., Microsoft, Atlassian, Google, Facebook, etc.) issue documentation for developers creating APIs that will be operable with the respective vendor's offerings. While any APIs developed to run on these platforms will be based on standard programming language used for APIs (e.g., Restful APIs, SOAP, etc.), these platforms will typically include proprietary features that can influence the coding used to create these applications. This effectively means that differences will exist between SaaS applications developed to run on each of these platforms with the result often being that interoperability problems can exist between applications that are intended to be functional with multiple platforms. User operability among various platforms can therefore be comprised.
Many potentially relevant SaaS applications for a cloud computing environment may be created by smaller companies, or even individuals, to solve very specific functionality needs, for example, as a “microservice” to drive a specific hardware product. These products are often generated from a “Lean Startup” framework. To this end, developers that are generating new products will create and test individual SaaS applications that are no more than “Minimum Viable Products” (“MVPs”) to determine whether a scalable market might exist. As dictated by “Lean Startup” principles, these MVPs are created to be just “good enough” to test a product concept. While the developers may generally adhere to development guidelines and associated coding conventions, the goal of such development is to get a testable product to the market as quickly as possible. As such, best practices in software development may not be strictly adhered to, at least at an early stage. Moreover, often the developers of these SaaS products are not professional developers, which would make it less likely that generated applications would closely conform to guidelines for API development. If market testing of a product associated with the application is successful, Lean Startup principles dictate that the company move ahead quickly to be able to capture and scale the market opportunity. This means that an application will be built upon, and any features present in the foundational aspects of the SaaS product will be propagated into the future. While IT administrators would vet and accept applications in previous generations of computing infrastructures, it would be apparent that users can be expected to select a SaaS application based on needed functionality, not on the underlying coding and interoperability thereof with a broader computing ecosystem.
Whether due to the variability between the proprietary API development guidelines set out for platforms or “bespoke” programming features that can be incorporated in a SaaS application, data object structuring resulting from processing of the object in each application can vary within and among vendors. Such differences may be subtle or marked, but the mere existence of deviations in data object structuring can greatly increase the complexity of managing the operations of SaaS applications programs by an IT department, especially in the context of managing data movement inside and outside of an organization.
The problem of inconsistencies in the processing of data in and among a plurality of SaaS applications is compounded by the sheer amount of information that must be actively managed in the modem IT infrastructure. To this end, every SaaS application has a web of data objects that reference, interact, control, and/or rely on each other. Examples include, in a non-exclusive listing, users, groups of users, database records (e.g., acquired data, tasks, opportunities, contacts, calendars, chats), mailboxes, files, folders, third-party applications (e.g., that have been installed from app marketplaces and authorized by users), logs, metadata, permissions, devices, policies, or phone numbers (e.g., numbers assigned to multiple endpoints like mobile applications, IP desk phones, and/or softphones that are included off an interactive voice response [IVR]/call tree). This web of data objects becomes inherently more complex in multi-SaaS application environments. For example, data objects may be connected (or overlap) across applications, but may nonetheless not be aware of each other. This “sprawl” means that is as yet no single place to view them all, such as in a dashboard format, for example.
As SaaS application adoption grows, so will the amount of data living in SaaS applications, which in turn creates an enormous, decentralized information sprawl. Where SaaS data lives, and the questions of who has access to it and where it is exposed, become nebulous, even while the need for managing this data becomes more stringent. Thus, a significant issue with SaaS application sprawl is that valuable corporate data becomes scattered across dozens of cloud applications, making it difficult to find, analyze, and deploy. The owner of the data may not know what cloud apps retain or have access to its data. This sprawl becomes amplified when companies have multiple instances of SaaS applications. For example, many companies have separate accounts of Slack, Zendesk, and/or Salesforce per department, business unit, or office location. The SaaS applications data in these environments can be even more fragmented because the same data may be distributed within and siloed across multiple implementations of the same SaaS program in the same organization.
For example, different departments in a company may generate different implementations of Salesforce based on individual needs, preferences, etc. It may follow that interoperability within the same organization between these implementations of the same SaaS program from the same vendor may be compromised as a result. It should be apparent that since some or all of the configuration and operation of these individual instances of a SaaS application (e.g., Salesforce, Slack etc.) are at a department level, IT administrators may not be able to ensure interoperability. Nonetheless, the need to manage data objects operating in the organization's cloud computing environment is not reduced.
The amount of operational data that each SaaS application generates can be overwhelming, as well. In G Suite, for example, an audit log entry is created every time a user views, creates, previews, prints, updates, deletes, downloads, or shares Drive content. Similarly, Salesforce's event-monitoring API creates event log files for logins, logouts, API calls, API executions, report exports, Visualforce page loads, and more. When multiplied by tens, hundreds, or thousands of users, it is apparent that the amount of information that needs to be managed to ensure that an organization properly stewards its data can quickly become unmanageable. This problem is compounded by the fact that an organization's data is continuously being changed, deleted, and added to on a continuous basis, often by many people.
As companies increasingly adopt SaaS applications, critical information is located across a number of distinct sources rather than stored locally on physical endpoints such as users' devices and on-premises servers. There is no consistency across SaaS applications. In multi-SaaS environments, settings are adjusted in different places (e.g., an admin console vs. a Team Settings page). Each application has its own “data silo,” even while data overlaps. For instance, Drive and Dropbox files can be shared in Slack. Depending on the environment, a user may be able to install as many third-party applications (e.g., Chrome extensions, bots, or marketplace applications) as he would like. Many of these SaaS applications work together in some way, and all it takes is one seemingly innocuous application integration to constitute a value-destroying data breach. Data objects all have different nomenclatures (e.g., a “group” vs. a “channel”). There is no single unified view or administrative vocabulary across SaaS applications for IT professionals. Not only does this mean IT departments must visit multiple disparate administrative consoles (e.g., dashboards) to carry out administrative tasks, but it also means they have no global view of their overall computing environment. Ultimately, this type of SaaS sprawl means IT has little to no control over what enters the environment. Without the ability to manage data flow among a plurality of SaaS applications, or to centralize and view its organization's data, IT departments lack effective oversight. This impairs the capacity to understand what's even happening in the environment.
It follows that the shift to SaaS applications requires new frameworks and tools to allow IT professionals to manage, secure, and support applications that are critical to the operation of their organizations. However, currently, there exists no structured way to manage enterprise SaaS applications, nor are there tools and techniques that can facilitate IT professionals' achieving their security goals and requirements with respect to data moving in and among various users, programs, and devices in cloud computing environments. In short, there remains a need for improvements in the ability to manage data objects in a computing environment that comprises a plurality of SaaS applications. The present disclosure provides these, and other, benefits.